Many organizations depend on large software environments for managing internal and external business data. For example, most corporations have a large databases and related applications for performing human resources functions, accounting, customer management, and so forth. These large environments often include many physical components, such as servers, as well as many software components, such as databases, client applications, backup and other administrative components, and so forth. Deployment and maintenance of large software environments consume a significant amount of time and effort spent by organizational information technology (IT) departments. One example of a large software environment is MICROSOFT™ Forefront Identity Manager (FIM) 2010 (and MICROSOFT™ Identity Lifecycle Manager (ILM) 2007 that preceded it). FIM provides an integrated and comprehensive solution for managing the entire lifecycle of user identities and their associated credentials in an organization, including identity synchronization, certificate and password management, and user provisioning in a single solution that works across heterogeneous environments that allows IT departments to define and automate the processes used to manage identities from creation to retirement.
One popular technique for handling changes to a large software environment is to deploy a test, or pilot, environment that closely mirrors a production environment. IT personnel can work safely within the pilot environment to try various modifications to the environment without the fear of affecting day-to-day business activities. The IT personnel can test configuration changes, add or remove servers, try additional software within the environment, and so forth in a relatively safe environment.
The problem is that once it is time to deploy the changes made in the pilot environment to production, it is often difficult to reconcile the significant differences that may have resulted from the divergence of the two environments during testing. Using identity systems as an example, identity objects contain a mixture of primitive value attributes and reference attributes that express relationships with other identity objects. Synchronizing primitive value attributes on identity objects is similar to synchronizing files in which the order of operations does not matter. However, business policy may dictate synchronization to occur in an order based on object relationships. For example, an employee object may only be valid if a corresponding manager object exists. Synchronizing objects based on relationships involves ensuring that the referred identity object exists, so order of operation matters. Existing solutions work around this problem by using retry logic. For identity-aware applications that require references be present (e.g. all employees have a manager), existing synchronization solutions cannot be used.